home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000149_owner-urn-ietf _Wed Nov 13 15:20:26 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11959 for urn-ietf-out; Wed, 13 Nov 1996 15:20:26 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11953 for <urn-ietf@services.bunyip.com>; Wed, 13 Nov 1996 15:20:23 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA14036  (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 15:13:19 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id PAA20767; Wed, 13 Nov 1996 15:12:48 -0500 (EST)
  7. Message-Id: <199611132012.PAA20767@ig.cs.utk.edu>
  8. X-Mailer: exmh version 1.6.7 5/3/96
  9. X-Uri: http://www.cs.utk.edu/~moore/
  10. From: Keith Moore <moore@cs.utk.edu>
  11. To: stu_weibel@oclc.org (Stu Weibel)
  12. Cc: urn-ietf@bunyip.com, moore@cs.utk.edu
  13. Subject: [URN] Re: I18N does not belong in URNs 
  14. In-Reply-To: Your message of "Mon, 11 Nov 1996 13:56:14 EST."
  15.              <199611111856.NAA20145@orc.NISOR> 
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset=us-ascii
  18. Date: Wed, 13 Nov 1996 15:12:48 -0500
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Keith Moore <moore@cs.utk.edu>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. Stu writes:
  25.  
  26. > Keith Moore writes:
  27. > 
  28. > > URNs aren't supposed to be human-meaningful.  Making them human-meaningful
  29. > > defeats the purpose of having them be long-term stable.
  30. >  
  31. > This reflects a philosophy, an attitude, a point of view that is NOT
  32. > shared in anything like a consensus in this group.  
  33.  
  34. As to the latter statement, I agree with you.  Many people do not
  35. believe (or are not yet convinced) that human-meaningful URNs are
  36. inherently nonpersistent over the long term.
  37.  
  38. Even I will concede that there might be a way out.  Tim Berners-Lee
  39. and others have suggested adding low-precision dates to URNs.  So
  40. (e.g.) the "199610" in the URN urn:inet:kodak.com/199610/gibberish
  41. would fix the meaning of "kodak.com" and any other human-readable
  42. strings within the URN to "the meaning of these words in the tenth
  43. month of 1996".  Maybe that would be sufficient.  There's no way to
  44. know for sure, since it depends on what people do in the future.
  45.  
  46. As to the former statement, in case there's any doubt as to "URNs aren't 
  47. supposed to be human meaningful", I refer interested parties to the group's 
  48. charter
  49. (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737,
  50. the requirements of which the charter incorporates by reference.  
  51.  
  52. Actually, I recommend that everyone here re-read RFC 1737, with
  53. particular emphasis on the Introduction.  It is a good description
  54. of the problem that this group was created to solve.
  55.  
  56.  
  57. > I say again...
  58. > this WG should adopt the *least restrictive* solution that is technologically
  59. > sound and let people do with it what their communities choose.  
  60.  
  61. That sounds reasonable, but by itself, it's not good engineering sense.
  62.  
  63. Here's an alternative view for consideration:
  64.  
  65.     This WG should adopt the *least complex* solution which meets the
  66.     various requirements of its charter, and which does not impose
  67.     unnecessary restrictions beyond those inherent in the problem space.
  68.  
  69. Of course, both of these positions are extreme.  Usually we want a
  70. solution that is not too complex to implement, but still has some
  71. extra flexibility to allow the solution, once deployed, to adapt to
  72. unanticipated uses.
  73.  
  74. But when people propose adding I18N support to URNs to make them human
  75. meaningful, I view this as adding a great deal of extra complexity in
  76. an attempt to make URNs solve a completely different problem than they
  77. were designed to solve.  (And given the history of various "information 
  78. infrastructure" groups at failing to narrow their scope to a problem that's 
  79. solvable in finite time, I get very nervous.)
  80.  
  81. By contrast, when people propose adding I18N support to URNs to allow them
  82. to incorporate URN-like names that happen to include one or two non-universal 
  83. characters, I wonder things like "Is it really worth the complexity?" and 
  84. "Which is more important, global scope and transcribability and single 
  85. encoding or the ability to easily grandfather all URN-like systems?"
  86.  
  87. Keith
  88.  
  89.